Field of the Invention
Embodiments relate to methods for transferring media data.
Background of the Related Art
Real-time communication for VoIP (Voice over Internet Protocol) or Video over IP creates a network overlay over existing IP network infrastructures. Real-time communication is sensitive to packet loss and packet transmission impediments (in particular packet loss, delay, jitter) and can therefore be detrimental to the user's quality of experience (QoE).
In IP networks with “standard L2/L3 QoS support,” traffic classes (QoS, Quality of Service) are differentiated and marked on the transmission layers 2 (layer 2, L2) and 3 (layer 3, L3). This marking makes it possible to apply different transmission priorities (Per-hop Behavior—PHB) to the network components in L2/L3 QoS-supporting networks, called QoS-sensitive networks in the invention (IEEE802.1p/DiffServ). PHB is applied on a per-packet basis based on the aforementioned markings. These markings can either be assigned at the media endpoint itself (internally) or handled externally using a recognized (media) data flow through a network element. Previously, an individual port number was assigned to each such (media) data flow, providing separation. The term “QoS-sensitive” in this case means that a PHB is executed per packet and in each node, also known as “QoS-aware.” The data flows for audio and video data typically consist of a series of IP/UDP packets containing a series of real-time protocol (RTP) protocol elements as the data payload.
A mix of traffic types such as audio, video, screen-sharing, data, or gaming through the same port or even within the same flow is technically possible with the protocol, of course, but until now has not been done and is therefore not supported by the switches (L2) and routers (L3).
In this regard, two different cases should be distinguished:
1. Different flows with the same media type using the same port number (port multiplexing); Advantages: Administrative burdens on servers and on network gateways involving the ports are reduced.
2. Different media types are transferred as service components in one and the same IP packet (service multiplexing within the IP packets, in addition to port multiplexing);
Advantages: Compared to 1. there is a greater reduction of the port administrative burden and less bandwidth use, because only one IP header is needed for multiple RTP protocol elements (lower protocol overhead).
In both cases, the aforementioned ability to assign a port to a service component or media type is lost.
In the 1st case, of course, internal marking and execution at the L2 and L3 levels still function as described, but there is no possibility for external marking based on the port number.
In the 2nd case, the standard marking technique also no longer applies, because the IP packet can only carry one marking, but there are (or can be) portions of different flows and differing media types within one IP packet, most of which require different marking values.
Transferring media data (real time and non-real time), e.g., directly out from the Internet or web browsers as occurs in the current WebRTC (also known as RTCWeb) standardization approach (e.g., for Firefox, Google Chrome, etc.), is a new technology currently being defined.
In multimedia applications, the selected assignment of port to flow with the previously described “standard QoS support” leads to increased administration and implementation expense and represents a significant obstacle particularly in getting past NATs (Network Address Translations) and firewalls, and especially in the desired mass market (e.g., Google Cloud services). Therefore, WebRTC should be removed from administrating individual connections, and thereby also from the various port associations, which should be accomplished by “port multiplexing” and/or “service multiplexing.”
It should be assumed that, after WebRTC technology is standardized and comes to be widely used, the L2/L3 network elements should also be given a WebRTC-compatible QoS approach. However, this transition (migration) is expected to occur only gradually and over a very long period of time. Introducing and implementing the standard QoS support was also a process that stretched over many years and is still not entirely complete.
The introduction of WebRTC (Real-Time Communication (RTC) over the Web) resulted in the urgent need for a transition/migration solution for existing network infrastructure.
To date this problem with WebRTC has not been solved. There is, of course, work being done on the SCTP (Stream Control Transmission Protocol), but these solutions do not apply to the UDP/RTP context being addressed here.
WebRTC can be used without port multiplexing (such as with SIP). In that case, however, the basic multiplexing advantages (see above) also cannot be used, either on the server side (e.g., with cloud-based systems) or for network gateways (firewall/NAT).